Automated tracker and analyzer

ABSTRACT

A utility that can be embedded within a system or application, or run as a stand-alone utility, provides a method for identifying causal relationships for one or more events. For instance, if an anomaly is occurring for a subset of events in a series of events, certain information about potential causes can be collected in conjunction with the series of events and, the information can be analyzed to determine if there is a cause and affect relationship leading to the occurrence of the anomalies.

CROSS-REFERENCE TO RELATED APPLICATIONS

This is a utility patent application being filed in the United States asa non-provisional application for patent under Title 35 U.S.C. §100 etseq. and 37 C.F.R. §1.53(b) and, is a continuation of the U.S. patentapplication Ser. No. 13/751,320 that was filed on Jan. 28, 2013, whichis a continuation-in-part of the U.S. patent application Ser. No.13/560,528 that was filed on Jul. 27, 2012, both applicationsincorporated herein by reference in their entirety.

BACKGROUND

Chaos theory studies the behavior of dynamical systems that are highlysensitive to initial conditions. Although this is a mouthful and alittle hard to grasp on first read, it is much more readily understoodwhen this is referred to by it more popular name—the butterfly effect.Briefly, the butterfly effect poses that small differences in initialconditions (such as those due to rounding errors in numericalcomputation) yield widely diverging outcomes for such dynamical systems,rendering long-term prediction impossible in general. The name of theeffect, coined by Edward Lorenz, is derived from the theoretical exampleof a hurricane's formation being contingent on whether or not a distantbutterfly had flapped its wings several weeks before. Although thebutterfly effect may appear to be an esoteric and unlikely behavior, itis exhibited by very simple systems: for example, a ball placed at thecrest of a hill may roll into any of several valleys depending on, amongother things, slight differences in initial position.

In many scenarios, it can be rather important to identify and correlatecauses and effects. One can appreciate that such capabilities would havegreat use and advantage in any of a wide variety of settings such as,production, healthcare, productivity, athletics, stock prices, etc., asa few non-limiting examples. Thus, being able to identify a nexusbetween causes and effects in several such scenarios, and then beingable to take action based on this information, could be the differencebetween (a) producing products that avoid or result in a productliability law suit, (b) life or death of a patient, (c) meeting orblowing through a deadline due to productivity, (d) winning or losingthe SUPER BOWL or (e) a rise or fall in a companies stock price.

However, as clearly seen by the butterfly effect example, the multitudeof causes and the multitude of effects can create an infinite list ofitems that need to be tracked, observed and analyzed. In addition, inmany situations the ability to draw a connection between the cause andeffect may be difficult, impossible or at least unverifiable, whichsimply leads to speculation. However, rather than having absolutecertainty with regards to causes and effects, there is at least abenefit that can be derived from assigning probabilities to variouscauses and effects.

Thus, there is a need in the art for a solution that can help trackvarious causes and effects and to identify some level of probabilitywith regards to the nexus of certain causes and effects. In ourelectronic and connected world, much automation can be implemented toprovide assistance in the tracking and analysis of causes and effects.

BRIEF SUMMARY

The present disclosure presents a novel technique for the provision of atracker utility that can be utilized to identify and track data that maybe correlated with specific events and, thus to help identify a causeand effect relationship. In general, the tracker utility allows for thedefinition of data records to be collected, and to collect and associatethat data with certain events. In some embodiments, the data definition,collection and recordation are manual processes performed by users. Inother embodiments the definition, collection and recordation areautomated processes that do not require user intervention. In yet otherembodiments, a blend of manual and automated operations may be included.

The tracker utility may be included in any of a variety of settingsand/or environments and be implemented in a variety of manners. Andalthough the general functions and operations of the tracker utility areconsidered novel, some of the various nuances and implementationdetails, in and of themselves, are also considered to be novel. In oneparticular embodiment, the tracker utility includes tasks that tracksomething specific, such as temperature, time, events, etc., or in someembodiments, may track multiple items. Each task within the trackerutility may represent a discrete item of data that may be collected andis typically associated with an event (i.e., a sale, an uncovereddefect, a delivery delay, a production increase, etc. as non-limitingexamples).

The tracker utility, whether embedded within a system or application, orrunning as a stand-alone utility, provides a method for identifyingcausal relationships for one or more events. For instance, if an anomalyis occurring for a subset of events in a series of events, certaininformation about potential causes can be collected in conjunction withthe series of events and, the information can be analyzed to determineif there is a cause and affect relationship leading to the occurrence ofthe anomalies.

In general, embodiments of the tracker utility operate tocollect/receive data that is or may be related to certain events in aseries of events. A goal of the tracker utility is to provide amechanism in which a causal relationship pertaining to an event, ormultiple events may be discovered. As such, for a series of events, adefinition is created with regards to data that is to be collected.There may or may not be a known causal relationship between the eventand the data. For instance, the data can be randomly selected, selectedbased on a suspicion or collected because of some evidence of a causalrelationship. For certain events in the series of events, data iscollected from one or more sources and then stored along withinformation pertaining to the event. Over time, this data can beanalyzed along with the events to determine is there is a cause andaffect relationship.

These embodiments, features and aspects are further described in thefollowing detailed description and the figures.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING

FIG. 1 is a functional block diagram of the components of an exemplaryenvironment or platform in which the tracker can be implemented or anapplication, module or routine utilizing the tracker can be implemented.

FIG. 2 is a non-limiting example of an environment in which the trackercan be implemented.

FIG. 3 is a screen shot from an exemplary status program that thecompany utilizes to keep track of production.

FIG. 4 is an exemplary screen shot illustrating the detailed history fora particular mold that has been actuated—shaft-423.

FIG. 5 is a screen shot from the exemplary status program as shown inFIG. 3 with the addition of the tracker utility.

FIG. 6 is an exemplary screen illustrating a conceptual user interfacefor defining data to be tracked for a particular event.

FIG. 7 is an exemplary screen for a data definition that is applicableto the current example.

FIG. 8 is an exemplary screen shot for an interface to allow a user toenter data related to a particular event or object, such as a mold inthe present example.

FIG. 9 is an exemplary screen shot for a supervisor interface operatingat the attributes level to expand the data collection.

FIG. 10 is an exemplary screen shot for defining the application of therule(s) based on various parameters.

FIG. 11 is an exemplary screen showing non-limiting examples of controlsthat can be imposed on the rules or the data collection at the marketdefined level.

FIG. 12 is a flow diagram illustrating actions that may occur in anexemplary embodiment of the tracker utility.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

This description is related to and is directed towards a tracker utilitythat can be incorporated into a variety of systems to enable thecollection, recordation and analysis of data related to a particularprocess, item, event, etc. (collectively and individually referred towithin this description as an event). Although various aspects, featuresand embodiments of the tracker utility are presented within thisdescription in specific embodiments and environments, such as aweb-based or web-centric accounting and general ledger system, it willbe appreciated that such environments are only non-limiting examples ofan environments that is suitable for various embodiments, configurationsand implementations of the tracker utility.

At a very high level, the tracker utility, or the tracker, is a utilitythat can be included in a variety of settings to allow a user toidentify and insert data for an event, allow management or others torequire or solicit the collection and input of data for an event and/orcausing automated process to search for, identify and collect data foran event. In addition, in some embodiments that tracker may be astand-alone application, such as an app for a smart phone, tabletcomputer, computer, etc. The data collected can then be used to guidethe event, augment other activities to cause different results, and/orlearn more information about the event or issues related to the event.The various embodiments of the tracker include three dimensions: (1)identification of an event that should be tracked; (2) implementation ofvarious levels of data accumulation and tracking related to the event;and (3) analysis of the collected information to make informedjudgments. Turning now to the drawings in which like elements arerepresented by similar labels, further details, features and embodimentsof the tracker utility are provided.

FIG. 1 is a functional block diagram of the components of an exemplaryenvironment or platform in which the tracker can be implemented or anapplication, module or routine utilizing the tracker can be implemented.It will be appreciated that not all of the components illustrated inFIG. 1 are required in all embodiments or implementations of the trackerbut, each of the components are presented and described in conjunctionwith FIG. 1 to provide a complete and overall understanding of thecomponents. In addition, it will be appreciated that the tracker may beimplemented in systems and/or environments that may include othercomponents and functionality and as such, the illustrated configurationis simply a non-limiting example.

The exemplary platform 100 is illustrated as including a processor 102and a memory element 104. In some embodiments the processor 102 and thememory element 104 may be communicatively coupled over a bus or similarinterface 206. In other embodiments the processor and the memory element104 may be fully or partially integrated with each other. The processor102 can be a variety of processor types including microprocessors,micro-controllers, programmable arrays, custom IC's etc. and may alsoinclude single or multiple processors with or without accelerators orthe like. The memory element of 104 may include a variety of structures,including but not limited to RAM, ROM, magnetic media, optical media,bubble memory, FLASH memory, EPROM, EEPROM, etc. In addition, ratherthan being internal to the platform 100, the memory element 104 may beexternal to the platform 100 and accessed through a device interface 112or network interface 114. The processor 102, or other components mayalso provide sub-components or functionality such as a real-time clock,analog to digital convertor, digital to analog convertor, sensors, etc.The processor 102 also interfaces to a variety of elements including acontrol/device interface 112, a display adapter 108, audio adapter 110and a network/device interface 114. The control/device interface 112provides an interface to external devices, systems, equipment, sensor,actuators or the like. As non-limiting examples, the control/deviceinterface 112 can be used to interface with devices or systems such as akeyboard, a mouse, a pin pad, and audio activate device, a PS3 or othergame controller, as well as a variety of the many other available inputand output devices or, another computer or processing device. Thedisplay adapter 108 can be used to drive a variety of visually orientedalert elements 116, such as display devices including an LED display,LCD display, one or more LEDs or other display devices. The audioadapter 110 interfaces to and drives a variety of audible or other alertelements 118, such as a speaker, a speaker system, buzzer, bell,vibrator, etc. The network/device interface 114 can also be used tointerface the computing platform 100 to other devices or systems througha network 120. The network may be a local network, a wide area network,wireless network (WIFI, Bluetooth, cellular, 3G, etc.), a global networksuch as the Internet, or any of a variety of other configurationsincluding hybrids, etc. The network/device interface 114 may be a wiredinterface or a wireless interface. The computing platform 100 is shownas interfacing to a server 122 and a third party system 124 through thenetwork 120. Thus, the computing platform can function independently, inconnection with one or more systems, or even as a distributed system. Abattery or power source provides power for the computing platform 100.

FIG. 2 is a non-limiting example of an environment in which the trackercan be implemented. The environment illustrated in FIG. 2 is aclient-server application environment 200. The client-server applicationenvironment is shown as including, but not limited to, the components ofan application client 210, a server 220 and a database 230. Theapplication client 210 communicates information to the server 220 overcommunication path A and receives communicated information from theserver 220 over communication path B. A protocol such as HTTPS may beused to provide data privacy for information that is communicatedbetween the application client 210 and the server 220 and enforcesclient authentication to limit access to the server 220 to authorizedusers. It will be appreciated by one of ordinary skill in the relevantart that the tracker could be incorporated into any local or distributedcomputing environment and the illustrated example is just provided forpurposes of explanation.

It will be appreciated that the computing platform 200 illustrated inFIG. 2, may then provide an environment on which an application,program, system, etc. can run, and that such application, program,system, etc., may incorporate aspects of the tracker utility or accessan external function or system that houses the tracker utility.Likewise, the computing platform 100 may also illustrate a platform inwhich a standalone embodiment of the tracker utility may reside, such asa smart phone, tablet computer, lap top computer, desktop computer, etc.

In the various embodiments, the tracker utility enables theidentification, capture and recordation of data that would not otherwisebe captured by a system or application. It should be appreciated thatthe tracker utility can be used for any of a variety of purposes, suchas process improvement, business activities, etc. In essence, any eventthat may have a cause and effect relationship based on other actions oractivities could benefit from the use of the tracker utility.

The tracker may be viewed as providing a multi-level approach to thecollection of data: (a) user defined level; (b) attributes level; and(c) market defined data level. It will be appreciated that these levelsare presented as an exemplary way to view the operation of the trackerbut, other views with more or fewer levels could also be described and,the operations of the tracker could be presented independent of thelevel view. But, for purposes of illustration, the tracker utility isdescribed in accordance with these three levels.

The user defined level includes an interface that enables a user of anapplication, program or process that includes the tracker utility, or auser of a standalone tracker utility, to record data related to anevent. As previously noted, the term event is used to generically referto any type of information, process, action, event, etc., that is beingtracked, monitored, analyzed, etc. For instance, within the environmentof a general accounting system, as will be described in more detailbelow, the event may be a transaction record, such as a purchase ofsupplies, the reception of an order, the delivery of product, etc. Atthe user defined level, the user can spontaneously enter data that isrelevant to the event. For instance, the data may simply include thetime of day associated with the event. In other embodiments, the datamay include the weather, the time, the day of the week, the temperature,the level of humidity, a current value for an exchange index such as theNEW YORK STOCK EXCHANGE, other current events, etc. The user definedlevel in essence is a preliminary step in the data collection process. Atypical example is that the user happens to take note of a certaincharacteristic at the time of the event and, not maybe not fullyunderstanding the relevance, importance, etc. decides to record dataassociated with the event. This is performed based on a decision by theuser as opposed to an automated function.

In operation, an application, program or system that embodies thetracker utility will include a user interface to allow the user to entersuch data. The user interface to access the tracker utility may bepersistent or may require an action on the part of the user to invoke,such as a pull down menu, icon on a function bar, etc. As onenon-limiting example, if the tracker utility is embodied within aspreadsheet environment, the user could select a particular cell andthen actuate the tracker utility to enter data related to thehighlighted cell. Upon being actuated, a window may be presented to theuser, or some other interface may be used, to allow the user to identifythe type of data being entered, the source of the data, the actual data,etc.

The next level of the tracker utility is referred to as the attributeslevel. The attributes level is an escalation of the user defined levelin that an additional force, other than the user is imposingrequirements for data collecting with regard to the event. As anon-limiting example, the user's management team may determine that datashould be collected on a larger scale (i.e. more users, collecting thedata with regards to the event rather than just one independent user or,similar data should be collected with regards to similar or relatedevents, etc.). As a result, rather than the data being entered by a useroperating on his or her own accord, the data collection can be refinedand expanded to include other users. Thus, as users of an application,program, etc., record an event, the tracker utility may automatically beinvoked to require the users of the application, or a subset thereof, toobtain and enter the requested data pertaining to the event.

The third level in the described embodiment is the market defined datalevel. The market defined data level is an escalation of the attributeslevel. Generally the market defined data level is invoked when it isdetermined that data should be collected from outside sources or devicesand that the data should be consistently and automatically collected.The market defined data level thus includes an interface to allow thedata collection to be automated. Such an interface may receivedirections such as the identification of sources for required data andhow to access those sources and how to retrieve the desired data, thetiming, frequency and intensity of the data collection, the verificationof the collected data, etc.

The following example is a non-limiting example of a particularapplication of the tracker utility and is provided to assist in anoverall understanding of an exemplary embodiment of the tracker utility.It should be appreciated that while certain aspects, functions andconfigurations presented in this example are considered novel, otherembodiments of the tracker utility are not limited to such aspects,functions and configurations. In the example, it is assumed thatemployees of a small shop are using the presented embodiment of thetracker utility and that the small shop manufactures custom ceramicsinks. In this hypothetical example, it is also assumed that the companyis having a problem with mold breakage. It has been discovered that onsome occasions, during the overnight curing period, a significant numberof the molds crack or break. The broken molds result in significantlosses and expenses for the company in that it increases costs formaterials, labor, and the adversely effects the production schedule. Themold breakage appears to occur intermittently, making it difficult forthe management to determine the actual cause. One of the employees atthe company wonders if there is a connection between the broken moldsand the weather, after noticing that the molds seem to be breaking moreoften in cool and humid or rainy conditions. The company uses softwareto monitor various aspects of production, such as the age and conditionof the molds used in a given production run. However, the employeediscovers the software cannot record additional data outside of itspreconfigured settings. The tracker function provides the means tocapture data “on the fly” for almost any conceivable variable a companymight want to track, for as long as the company wants to track it. Thefollowing paragraphs describe the interaction between the trackerfunction and existing software.

FIG. 3 is a screen shot from an exemplary status program that thecompany utilizes to keep track of production. For each of the molds, thestatus program includes the mold identification 310, the date that themold was used for this current report 312, the production quality of theresulting product (Flawless, Good, Fair, Rejected) 314 and the conditionof the mold (Flawless, Good, Fair, In Repair, Cracked, Chipped,Scratched, Junked) 316. At the end of a production cycle, the statusprogram allows a technician to record the date that a particular moldwas used, the quality of the product produced and the current conditionof the mold. The status program presents a screen 300 that presents alist of the molds and the latest status for the mold. If more molds arein production than the screen can hold, the user can scroll to differentpages by selection one of the navigation buttons on the bottom of thescreen (FRST PAGE 320, LAST PAGE 322, PRV PAGE 324 and NEXT PAGE 326) orby using the scroll bar 328. By selecting a particular mold ID, thestatus program switches over to a detailed view of the history for thatparticular mold.

FIG. 4 is an exemplary screen shot illustrating the detailed history fora particular mold that has been actuated—shaft-423. On the top of thescreen 400, the screen title 410 shows that this is a history report forshaft-423 mold. The history table includes a column to identify thedates of use of the mold 412, the time the mold was put into use 414,the time when the mold was removed from use 416, the quality of theproduct produced (Flawless, Good, Fair, Rejected) 418 and the conditionof the mold (Flawless, Good, Fair, In Repair, Cracked, Chipped,Scratched, Junked) 420. Thus, it can be appreciated that using theexemplary status system, the user can keep track of each mold, gain aview of the current status of the molds as in FIG. 3 or look at thehistory of any particular mold FIG. 4. However, what is not available isthe ability to identify information to track with regards to the usageof the mold.

FIG. 5 is a screen shot from the exemplary status program as shown inFIG. 3 with the addition of the tracker utility. As previouslymentioned, the tracker utility may be a stand alone program, application(such as a smart phone app) or may be integrated into any of a varietyof other programs, systems, etc. In the illustrated embodiment, thetracker system is integrated into the status program. A user of thetracker system can access the tracker utility by actuating the trackerbutton 510 next to the data entry for a particular mold.

With the tracker utility equipped status program, the user may, on hisor her own initiative, use the tracker utility as a first level of datacollection (user defined level) to begin the recordation of data withregards to an event related to a particular mold. When the use entersthe status information for a mold, the user simply actuates the trackerbutton 510 to pull up a window, screen, dialog or some other form ofuser interface to allow the user to either define the data to be enteredor, to enter data that satisfies the definition requirement.

FIG. 6 is an exemplary screen illustrating a conceptual user interfacefor defining data to be tracked for a particular event. The interface600 includes a field to define a name for the data 610, the format inwhich the data is to be entered 612 and a description of the data 614.It should be appreciated that a variety of rules may also be created asenforcement with regards to the data entry. For instance, ranges can bedefined, accepted values and rejected values can be defined, etc. Otherfields may also be included such as identifying the source of theinformation, identifying the accuracy of the information, identifyingthe time that the data was collected, the date the information wascollected, whether the data was cross-correlated with other sources andif so how many and what was the average, mean and/or standard deviationbetween the sources, etc.

FIG. 7 is an exemplary screen for a data definition that is applicableto the current example. For the illustrated embodiment, the user hascreated two data fields, one for the temperature 710 and one for thehumidity 720. The temperature data field is called TEMP, and thedefinition identifies the format for the data entry and provides adescription of the data. The humidity data field 720 is called HUMIDITYand likewise identifies a form for the data entry and provides adescription of the data. Once the data fields are defined, when the useractuates the tracker utility button 510, the user may be prompted todefine a data field, redefine a data field or to enter data. If the userselects to enter data, an interface is presented to the user forentering the data.

FIG. 8 is an exemplary screen shot for an interface to allow a user toenter data related to a particular event or object, such as a mold inthe present example. In the illustrated example, the user has enteredthe temperature of 52 degrees and the humidity value of 85%. Onceentered, this information becomes part of the history of the mold beingevaluated and thus, can be searched on, reviewed and analyzed withregards to the condition of the mold.

At this level of operation, the user records the temperature andhumidity from a user selected or identified data source (i.e., thesource could be a website such as weather.com, a radio or televisionbroadcast, instrumentation, etc.). Whatever the source of the data, theuser obtains the data and manually enters the data in conjunction withthe recordation of the event. Thus, in some embodiments, the trackerutility may include the ability to tack such data to any particularevent or various events recorded in the system but in other embodiments,the user may be required to define or create a special field in atransaction screen or otherwise record the data and associate it withthe event.

In the example being presented, suppose that after a few weeks ofrecording the data, the data collected by the employee tends to confirmhis or her initial suspicion—mold breakage appears to be more frequentand/or severe on days in which the temperature is cooler and thehumidity is high. The employee then presents his or her findings to thesupervisor. In this particular example, the supervisor may conclude thatthe theory is worth being monitored more closely and thus, can impose arequirement on all shifts to begin collecting and recording data aboutthe temperature and humidity along with mold status/evaluation events.The supervisor utilizes the attributes level to expand the datacollection to more users, and as a result, is able to monitor the datacollected.

FIG. 9 is an exemplary screen shot for a supervisor interface operatingat the attributes level to expand the data collection. In screen 900 thesupervisor is first prompted to select one or more of the tracker datafields for which to create a tracker rule. The user simply selects thecheck box next to the data field name to select it. In the illustratedexample, the supervisor has selected the TEMP and HUMIDITY data fieldsfor the rule.

FIG. 10 is an exemplary screen shot for defining the application of therule(s) based on various parameters. In the illustrated non-limitingexample, an ALL USERS box 1010 is provided to allow the rule to beapplied to all users of the system. Alternatively or in addition, aSELECT USERS box 1012 may be provided to allow the supervisor to selectone or more of any of the listed users. Check boxes may be utilized, aswell as certain format attributes to show that the particular users havebeen selected.

Similarly, the rule can be applied against all molds by actuating theselection box next to the ALL MOLDS button 1014 or one or moreindividual molds can be selected for the application of the rule.

In addition, the non-limiting example also shows the SELECT FREQUENCYparameter entry 1018 which allows the supervisor to decide when, and howoften the data is to be collected. Thus, the users may be required togather and enter the data once every other use of the mold, once a week,twice a day, etc.

It will be appreciated that a wide variety of other parameters may alsobe used and the various embodiments of the tracker utility anticipatesuch other parameters and thus the examples provided herein arenon-limiting. Other non-limiting and non-illustrated parameters mayinclude groups or classes of people, shifts, geographical locations,classes of products, etc.

In the illustrated example, the supervisor has selected the rule to beapplied against all users and all molds.

Once the rules have been defined, then in operation the data can be moreeasily and reliably collected. For instance, as a non-limiting example,after a user enters status information with regards to a particularevent, the user may be forced to enter the tracker information beforemoving on to the next screen or action. A dialog or user interface maypop up on the screen prompting the user to take the necessary action,such as visiting a particular content source to gather applicable data.Some embodiments may provide an override button but other embodimentswill require the data to be entered before moving forward.

Continuing with the present example, suppose that after a period of timeof collecting the data and analyzing the data, the supervisor realizesthat the majority of the temperature and humidity readings are beingcollected from the website of the local airport. Upon conducting furtherresearch, the supervisor determines that these temperature readings areonly updated periodically through the day and are not updated at allbetween the hours of 8 pm to 8 am. As such, any fluctuations in thetemperature and humidity that would occur during these timeframes, whichis the time frame that the kilns typically run, were not beingaccurately recorded. The supervisor then decides to install probes inthe shop for measuring temperature and humidity.

The supervisor may also impose the collection of data at the marketdefined data level. At this level, in the present example, thesupervisor is able to enforce the recordation of temperature andhumidity readings at specific times, under specific conditions and in anautomated manner. For the market level, similar to the attributes level,the supervisor may be presented with a screen similar to the oneillustrated in FIG. 9, which allows for the selection of data fields.Alternatively, the supervisor may be presented with a list of rules thathave already been defined as well as the ability to define a new rulefollowing in the steps of the attributes level.

At the market defined data level, the automation and consistency isadded into the process and the user interaction is limited, reduced oreliminated all together.

Using the data collected with the tracker utility, the company was ableto identify the range of temperature and humidity in which mold breakagewas most likely to occur and then implement preventive measures whenneeded to alleviate the breakage issue. Advantageously, adjustmentscould then be made to greatly limit the number of mold breakages andproductivity and profitability can be realized.

FIG. 11 is an exemplary screen showing non-limiting examples of controlsthat can be imposed on the rules or the data collection at the marketdefined level. It will be appreciated that additional or alternativecontrols could be utilized in various embodiments, as well as variationsof the controls described herein. One of the illustrated controls allowsthe user to enter or select a data source 1110. The data source isselected as the one or more sources from which the system will pull thedata. For instance, if the tracker utility is to collect temperature,the user may be presented with a list of websites or sources forreceiving the temperature readings. In addition or alternatively, theuser may be allowed to define and enter a custom source. The sources mayinclude websites, local instrumentation, phone accessible data, or anyof a variety of other sources. In addition, in some embodiments multiplesources may be selected and data can be collected from each of thesources and compared for data integrity. Although the market definedlevel of data collection typically runs automatically without userintervention, it should be appreciated that in some embodiments, thetracker utility may prompt the user to gather and enter the data ratherthan automatically collecting it. In other embodiments both types ofoperations may be optionally enabled.

Another control may be utilized to set the schedule the data collection,assimilation, analysis and recordation 1112. For instance, in anexemplary embodiment the user may be able to select a schedule forcollecting data samples but to set a different schedule for analyzingthe data, such as calculating a mean value or average value, and then aschedule for recording the analyzed data. In other embodiments, the usermay simply identify a single schedule for collecting and recording thedata. The schedule can be set up to select particular days, intervals,or even aperiodic points on the calendar. In addition, the schedule canidentify the time or time ranges in which the data is to be collected.The schedule may include a combination of dates and times or, simplydates or times. Once the schedule is set, the tracker utility may thenautonomously run, collect, analyze and record the data in accordancewith the settings. As previously mentioned, in some embodiments userintervention may also be included to request the user to verify orvalidate data or to prompt the user to collect and enter the data ratherthan automatically accessing the source or for sources for which thetracker utility may not have direct access.

Another control in some embodiments allows the user to select dataprocessing for the collected data 1114. The data processing can includea variety of functions and a few non-limiting examples include:calculating statistics related to the data, such as averages, means,standard deviations, etc.; validating data by various means by comparingto expected values, historically related values, etc.; establishingranges of valid data; setting a minimum sample requirement for datasamples, such as X samples or samples from Y sources; etc.

In various embodiments, the users can select user triggers 1116. Theuser triggers can run along with or in lieu of the data collectionschedule. The user triggers define actions in the underlying system orprocess that trigger the collection and/or recordation of data. Forinstance, events that may occur at different times in a system orprocess do not lend themselves to a fixed schedule for data collection.Thus, rather than the schedule, the events themself may trigger thecollection and/or recordation of the data. In the present example, anevent may include the removal of the mold from the kiln or, the turningoff of the kiln. Similarly, an event may include the turning on of thekiln or the placement of the mold within the kiln. Further, the turningon and off of the kiln may be events that bookmark the beginning andending of a data collection period and the data collections may run inaccordance with a set schedule during the data collection period.

Another option is to create or select filters for the application of thetracker utility functions 1118. As such, the collection and/orrecordation of the data can be filtered based on users,products/processes, etc.

When a filtered task is created, the filters can be used to associatethe task with the desired module/screen/user combination. As anon-limiting example, if an administrator wants receiving clerks totrack how many shipments arrive at their dock containing broken items,he or she can create that task and then assign it to the IN ShipmentEntry screen of an in-processing system and to specific users (i.e.,receiving clerks). An administrator can make the task required in orderto save a given record. Thus, for such a receiving clerk to save arecord reporting the reception of inventory, the task is invoked therebyrequiring the clerk to enter the required data. As a visual indicator,the tracker button may look different on different screens to indicatedifferent functionality—such as to differentiate between requiredactions and recommended actions.

Embodiments of the tracker utility will allow tasks to be tied tospecific transactions or events, as well as groups of events of classesof events. As such, a manager or supervisor can tie tasks to specifictransactions or, in some embodiments, the system may dynamically assigntasks to certain transactions based on an automated analysis of thetransactions and/or data previously collected with regards to thattransaction. The data recorded becomes part of the transaction recordand can therefore be included in a report if needed, searched, sorted,etc. When tasks are not tied to specific transactions, data collected isstored in its own table. The table could be exported in a format used bycommon spreadsheet programs. In some embodiments, the users are requiredto actuate a button or menu item or otherwise to invoke the tasks but inothers, the tasks can be configured to record data automatically withoutuser input.

The task can be associated with almost any combination of module,screen, function, event and user. This association can be accomplishedusing a variety of techniques, such as filters, sticky bits, flags, etc.Further, a task can also be created with no associations (unfiltered).An unfiltered task will display on all screens that include the trackerfunctionality. For instance, in embodiment, certain screens may includea tracker soft button that can be actuated to invoke the trackerfunction.

If any particular screen, data entry, event, etc. includes the trackerutility, in some embodiments users can collect data at any time simplyby invoking the tracker utility. This can be accomplished in a varietyof techniques including drop down menus, key sequences, actuating a softbutton, etc. In an exemplary embodiment, invoking the tracker utilitycauses the tracker user screen dialog to be displayed. From the trackeruser screen dialog, the user can then create a task that is specificallyassociated with that user. Thus, other users would not see or haveaccess to the task even though they may be accessing the same screen.However, managers or supervisors would typically have access and receivenotifications of the creation of such user-initiated tasks and haveaccess to the controlling the task, modifying the task, reviewing datacollected, assigning the task to other users, etc. Such actions could beaccomplished by giving authorized persons access to the task managerscreen.

Embodiments of the tracker utility may allow authorized users to create,assign and manage tasks. Tasks would be available for assignmentthroughout the system as described above. Managers would also be able toview user-initiated tracker entries and modify/delete them as needed. Ina particular embodiment, the display would essentially be a series oftables. One table might display user-level data items. Another tablemight display a list of existing data items. Highlighting one of theitems in a table would cause its details (including collected data) todisplay in another table.

U.S. patent application Ser. No. 13/560,528, incorporated above byreference, presents details of a web-centric accounting and generalledger system. Such a system may include an embedded tracker utility. Insuch an environment, the tracker utility may be available and associatedwith various screens, data records, etc., within the accounting andgeneral ledger system. A non-limiting example of the application of thetracker utility within this environment would include performing orsetting a data collection to occur on the event of entering a foreigncurrency deposit into the system. Upon the occurrence of such an event,the user or system may access a system to obtain the current exchangerate for that currency and enter that data into the system. As anotherexample, a tracking task can be set up to analyze payments received foraccounts receivable. A company may want to determine if there is anycorrelation between the date that their customers submit payments foroutstanding receivables. In such an application, the company may try toidentify data samples that could be collected that may provide such anindication. For instance, if a customer submits payment ranging from 30days after invoicing to 60 days after invoicing, the company may want tosee if a correlation can be identified and if so, attempt to identify aremedy for the situation. For example, suppose the customer was veryreliant upon timely shipments of their products. The company, amongother things, obtained data samples for the number of FEDEX and UPStrucks that would hub through the city headquarters on a daily basis.The data indicated that while the number of trucks remained somewhatconstant, the weight of the loads varied greatly. Further, the loadweights seemed to have a correlation with the payment schedule for thecustomer. Understanding that the delivery trucks has a maximum loadweight that they could haul, it was apparent that the periodicallyoccurring increased load weights were resulting in delayed deliveries ofthe customer′ inventory. Armed with this information, the company wasable to determine that another of their customers had an increased levelin orders from the company and those increases tended to coincide withthe increased load weights of the trucks. The company then was able toconclude, and verify with further collection of data that when thesecond customer had an increase in orders, that this would result in adelay of payment from the first customer in about a one month period oftime. They were able to convey this information to their customer sothat the customer could plan ahead with regards to upcoming shipments.Thus, in this example it is shown not only how the collection of datacan help to identify cause and effects on certain events but also howinformation within a companies system can be cross-correlated to help tofurther facilitate such analysis.

FIG. 12 is a flow diagram illustrating actions that may occur in anexemplary embodiment of the tracker utility. The tracker utility 1200 isincluded with or operates in conjunction with an application or systemthat may collect information about or otherwise monitor a series ofevents, actions or data (collectively referred to as events). Inutilizing the tracker, a series of events is identified 1202 for whichit is desired to determine or find a causal relationship for certaincharacteristics of one or more of the events. For instance, if one ormore of the events differentiates from expected outcomes, then the datacan be collected in an attempt to find the reason that these eventsdeviate from the norm or expected results. Next, the data to becollected for this determination is defined 1204. Data or informationcan be identified that hypothetically could have an effect on theevents. The format and type of data is thus defined such that the datacan be reliably collected and entered into the system. Next one or moresources for the data is identified 1206. The source can be a remotesource accessible through a network, a local source or a variety ofsources that are either directly or indirectly accessed. Once the seriesof events, data points and sources are identified, for at least aportion of the events 1208, data points are collected 1210 and thenstored along with event information 1212. The portion of the events maybe selected based on a schedule, based on parametric values such asusers associated with the events, time of day, day of week, etc., aswell as other factors. Once data has been collected, the data can beanalyzed 1214 to determine if there is a causal effect shown between thedata and the event deviations.

In the description and claims of the present application, each of theverbs, “comprise”, “include” and “have”, and conjugates thereof, areused to indicate that the object or objects of the verb are notnecessarily a complete listing of members, components, elements, orparts of the subject or subjects of the verb.

The present invention has been described using detailed descriptions ofembodiments thereof that are provided by way of example and are notintended to limit the scope of the invention. The described embodimentscomprise different features, not all of which are required in allembodiments of the invention. Some embodiments of the present inventionutilize only some of the features or possible combinations of thefeatures. Variations of embodiments of the present invention that aredescribed and embodiments of the present invention comprising differentcombinations of features noted in the described embodiments will occurto persons of the art.

It will be appreciated by persons skilled in the art that the presentinvention is not limited by what has been particularly shown anddescribed herein above. Rather the scope of the invention is defined bythe claims that follow.

1. A processor implemented method of processing accounting data in whichancillary information, in conjunction with a series of transactions, iscollected and analyzed to identify a correlation measure between theancillary information and the series of transactions, the processoroperating in response to executing program instructions, the methodcomprising the acts of: receiving a selection of a transaction that ispart of a first series of transactions; receiving ancillary informationto be associated with the first series of transactions by one or more ofthe following methods: receiving the input of ancillary informationdirectly entered by a user for the first series of transactions;receiving a system initiated request to collect ancillary informationfrom a first set of data sources; receiving ancillary data from one ormore data sources of the first set of data sources wherein the one ormore data sources operate to define the ancillary data and autonomouslyprovide the ancillary data to the system; and receiving the input ofancillary information entered from multiple users in response to asystem request imposed upon the multiple users; whereby, for a pluralityof transactions in the first series of transactions, the receivedancillary data and the transactions are analyzed to identify acorrelation measure.
 2. The method of processing accounting data ofclaim 1, wherein the transaction is at least one of a group comprising afinancial transaction, a business transaction, and an accountingtransaction and, the method can be enabled and disabled by a user. 3.The method of processing accounting data of claim 1, additionallycomprising the act of identifying the plurality of transactions of thefirst series of transactions by applying a filter to the first series oftransactions.
 4. The method of processing accounting data of claim 1,additionally comprising the act of defining a schedule for thecollection of the ancillary data.
 5. The method of processing accountingdata of claim 4, wherein the schedule identifies collection times aroundthe transaction.
 6. The method of processing accounting data of claim 1,additionally comprising the act of receiving a selection of atransaction that is part of a second series of transactions, and whereinthe act of receiving ancillary information to be associated with thefirst series of transactions additionally comprises one or more of thefollowing methods: receiving the input of ancillary information directlyentered by a user for a second series of transactions; receiving asystem initiated request to collect ancillary information from a secondset of data sources; and receiving ancillary data, similarly defined asthe received ancillary data for the first series of transactions, fromone or more data sources of the second set of data sources wherein theone or more data sources autonomously provide the ancillary data to thesystem; wherein the second set of data sources comprises the first setof data sources.
 7. The method of processing accounting data of claim 6,wherein the act of receiving ancillary information to be associated withthe second series of transactions includes two or more of the methodsand, wherein the second series of transactions comprises the firstseries of transactions.
 8. An accounting system for identifying acorrelation measure between ancillary information associated with aseries of transactions, the accounting system comprising: a memoryelement configured to store accounting data and program instructions; asource interface to one or more data sources, the data sourcesconfigured to provide accounting data related to a transaction and toprovide data entries not defined or requested by the processor; a userinterface; and a processor communicatively coupled to the memoryelement, the source interface, and the user interface, the processorconfigured to collate data from the source interface of the data sourcesvia a data request, the processor, in response to executing programinstructions contained in the memory element, being configured to:identify a transaction that is part of a first series of transactions;define a data entry to collect for the first series of transactions;request, from a first set of data sources, the defined data entry forthe identified transaction; receive, from any subset of the first set ofdata sources, the defined data entry for the identified transaction;receive, from any subset of the first set of data sources, a sourcedefined data entry for the identified event; and for a plurality oftransactions in the first series of transactions, analyze the defineddata entries, the source defined data entries and the transactions for acorrelation measure.
 9. The system of claim 8, wherein the processor isadditionally configured to identify the plurality of transactions of thefirst series of transactions by applying a filter to the first series oftransactions.
 10. The system of claim 8, wherein the processor isadditionally configured to define a schedule for the collection of thedefined data entries.
 11. The system of claim 10, wherein the scheduleidentifies collection times around the event.
 12. The system of claim 8,wherein the processor is additionally configured to: identify atransaction that is part of a second series of transactions; define adata entry to collect for the second series of transactions, the defineddata entries for the second series of transactions similarly defined asthe source defined data entry of the first series of transactions; andrequest, from a second set of data sources, the defined data entry forthe identified transaction; and wherein the second set of data sourcescomprises the first set of data sources.
 13. The system of claim 8,wherein the second series of transactions comprises more transactionsthan the first series of transactions.
 14. The system of claim 8,wherein the transaction is at least one of a group comprising afinancial transaction, a business transaction, and an accountingtransaction.
 15. A processor implemented method of processing accountingdata in which ancillary information, in conjunction with a series oftransactions, is collected and analyzed to identify a correlationmeasure between the ancillary information and the series oftransactions, the processor operating in response to executing programinstructions, the method comprising the acts of: receiving a selectionof a transaction that is part of a first series of transactions aselection of a transaction that is part of a second series oftransactions; receiving ancillary information to be associated with thefirst series of transactions and the second series of transactions byone or more of the following methods: receiving a first input ofancillary information directly entered by a user for the first series oftransactions, and a second input of ancillary information directlyentered by a user for the second series of transactions; receiving asystem initiated request to collect the first input of ancillaryinformation from a first set of data sources, and to collect the secondinput of ancillary information from a second set of data sources;receiving the first input of ancillary data from one or more datasources of the first set of data sources wherein the one or more datasources operate to define the ancillary data and autonomously providethe ancillary data to the system; and receiving the second input ofancillary data, similarly defined as the received first input ofancillary data, from one or more data sources of the second set of datasources wherein the one or more data sources autonomously provide theancillary data to the system; and receiving the first input of ancillaryinformation and the second input of ancillary information entered frommultiple users in response to a system request imposed upon the multipleusers; whereby, for a plurality of transactions in the first series oftransactions and the second series of transactions, any receivedancillary data and the transactions are analyzed to identify acorrelation measure.
 16. The method of processing accounting data ofclaim 15, additionally comprising the acts of identifying the pluralityof transactions of the first series of transactions and the secondseries of transactions by applying a filter to the series oftransactions.
 17. The method of processing accounting data of claim 15,additionally comprising the acts of defining a schedule for thecollection of the ancillary data.
 18. The method of processingaccounting data of claim 17, wherein the schedule identifies collectiontimes around the transaction.
 19. The method of processing accountingdata of claim 15, wherein receiving ancillary information to beassociated with the first series of transactions includes two or more ofthe methods and, wherein the second series of transactions comprises thefirst series of transactions.